Skip to main content

Platform Directory

Software that implements parts of a digital health architecture. Categorised by the architectural role it fills, because that is how the selection question is actually asked: "we need a shared health record — what are the options?"

Last verified: 2026-08-24. Project activity and versions change. Verify the repository's recent commit history and release cadence before committing to a platform, and treat the "status" column as a prompt to check rather than an assurance.

A platform is not an architecture. Choosing OpenMRS does not give you a health information exchange, and choosing OpenHIM does not give you interoperability — see interoperability for what else is required.


EMR / EHR​

ProjectDescriptionLicenceLanguageStandardsStatus
OpenMRSModular EMR platform designed for low-resource settings; concept dictionary modelMPL 2.0 / HL7Java, JavaScriptFHIR (module), HL7 v2, CIEL/SNOMED/LOINC dictionariesActive, large community
OpenEMRAmbulatory EMR and practice management, long-establishedGPLPHPFHIR, HL7 v2, CCDAActive
BahmniHospital system assembling OpenMRS, OpenELIS and OdooAGPLJava, JavaScriptInherits OpenMRSActive
GNU HealthHospital and health information system, includes lab and social medicine modulesGPLPythonHL7 FHIR, ICDActive
EHRbaseopenEHR clinical data repositoryApache 2.0JavaopenEHR, AQLActive

HMIS and routine reporting​

ProjectDescriptionLicenceLanguageStandardsStatus
DHIS2Aggregate reporting, tracker programmes and analytics; the de facto national HMIS in many countriesBSDJava, ReactADX, FHIR (partial), its own metadata APIActive, very large deployment base

Interoperability layer and integration​

ProjectDescriptionLicenceLanguageStandardsStatus
OpenHIMThe OpenHIE reference interoperability layer: routing, mediators, transaction logMPL 2.0Node.jsFHIR, HL7 v2, arbitrary via mediatorsActive
Mirth / NextGen ConnectMature health integration engine; strong HL7 v2 toolingMPL (open core)JavaHL7 v2, FHIR, X12, DICOMActive, commercial editions
Apache CamelGeneral integration framework with health componentsApache 2.0JavaFHIR, HL7 v2 via componentsActive
Apache NiFiFlow-based data routing, better suited to bulk pipelinesApache 2.0JavaGenericActive
OpenFnWorkflow automation and integration used in global healthLGPLElixir, JavaScriptFHIR, DHIS2, CommCare adaptorsActive

See integration engines for the selection criteria.

FHIR servers​

ProjectDescriptionLicenceLanguageNotes
HAPI FHIRThe Java reference implementation: client, server, validation, terminologyApache 2.0JavaThe most common self-hosted choice
Firely Server / .NET SDK.NET implementation; SDK open source, server commercialVariesC#Strong validation tooling
AidboxCommercial FHIR platform with a free tierCommercialClojureConfigurable storage model
Google Cloud Healthcare APIManaged FHIR, HL7 v2 and DICOMCommercial—See GCP
Azure Health Data ServicesManaged FHIR and DICOMCommercial—See Azure
AWS HealthLakeManaged FHIR data store with analyticsCommercial—See AWS
MedplumOpen-source FHIR-native application platformApache 2.0TypeScriptIncludes app framework and auth

Fuller comparison in FHIR servers.

Terminology​

ProjectDescriptionLicenceNotes
SnowstormSNOMED International's terminology serverApache 2.0The standard choice for SNOMED CT hosting
OntoserverCSIRO terminology serverCommercial, free in some jurisdictionsWidely used nationally
Open Concept Lab (OCL)Terminology and dictionary management, used with OpenMRSMPLCuration-oriented
HAPI FHIR terminologyTerminology operations within HAPIApache 2.0Sufficient for many deployments

See terminology services.

Registries​

ProjectRegistryLicenceNotes
OpenCRClient registryApache 2.0OpenHIE community; FHIR-based matching
SanteMPI / SanteDBClient registry / health data platformApache 2.0IHE and FHIR interfaces
iHRISHealth workerGPLHuman resources for health
GOFRFacility reconciliationApache 2.0Facility list matching across sources

See registries.

Identity and access​

ProjectRoleLicenceNotes
KeycloakIdentity and access managementApache 2.0OIDC, SAML, federation, token exchange; the common choice
Ory Hydra / KratosOAuth server / identityApache 2.0API-first, composable
Open Policy AgentPolicy decision engineApache 2.0Externalised authorisation
Vault / OpenBaoSecrets and key managementMPL / MPLSee security architecture

Laboratory, imaging, supply chain, financing​

ProjectDomainLicenceNotes
OpenELIS GlobalLaboratoryMPLUsed in several national deployments
SENAITELaboratory (LIMS)GPLPlone-based, research and public health labs
OrthancImaging (DICOM server)GPLLightweight, strong REST/DICOMweb API
dcm4che / dcm4chee-arcImaging archiveMPL/GPLProduction-scale archive
OHIF ViewerImaging viewerMITZero-footprint web viewer
OpenLMISSupply chainAGPLLogistics management
openIMISHealth financing / insuranceAGPLClaims and beneficiary management

Community health and data collection​

ProjectRoleLicenceNotes
Community Health Toolkit (CHT)CHW application frameworkAGPLOffline-first, SMS-capable
CommCareMobile data collection and case managementOpen coreWidely deployed
ODK / ODK-XMobile data collectionApache 2.0Survey and structured capture
KoboToolboxData collectionAGPLHumanitarian and health surveys
DHIS2 Android CaptureOffline capture for DHIS2BSDTracker and aggregate

See community health and offline-first.

Workflow and decision support​

ProjectRoleLicenceNotes
CamundaBPMN workflow engineApache 2.0 (community)Executes the BPMN from a DAK
TemporalDurable workflow orchestrationMITLong-running, failure-tolerant processes
n8nLow-code automationSustainable use licenceUseful for glue, not for clinical workflow
CQF Ruler / cqf-toolingCQL evaluation on FHIRApache 2.0Executes SMART Guidelines decision logic
OpenCDSClinical decision supportApache 2.0Verify current activity

Data platforms​

TechnologyRole in healthNotes
PostgreSQLThe default operational database for most of the abovePostGIS for spatial
MySQL / MariaDBUsed by several platforms
MongoDBDocument storage, used by some FHIR serversLicence is SSPL — check policy fit
Elasticsearch / OpenSearchSearch, log analyticsLicence differs between the two
ClickHouse / DuckDBAnalytical query enginesIncreasingly used for indicator computation
Kafka / RabbitMQ / NATSEvent and message transportSee integration

Choosing​

Six questions, in this order:

  1. Which architectural role does it fill? If two candidates fill different roles, you are not comparing them.
  2. Which standards does it actually implement, at which version, and is there conformance evidence?
  3. Can your team operate it? Operational complexity is the most commonly underestimated cost, and the one that determines whether the deployment survives.
  4. What is the community's health? Commit frequency, release cadence, number of independent contributors, and whether there is more than one organisation depending on it.
  5. What is the exit? Is the data extractable in a standard format, and what would migration cost?
  6. What is the total cost over ten years, including hosting, support, upgrades and the staff to run it?

Question 3 disqualifies more candidates in practice than question 2.


References​

Project sites are linked from each platform's page. Community directories worth consulting: the Digital Public Goods Registry (https://digitalpublicgoods.net/registry/), Digital Square Global Goods (https://globalgoodsguidebook.org/), and the OpenHIE community (https://ohie.org/).